Meta-modeling and modularity : Comparison between MOF, CDIF & sNets formalisms

Our aim in this article is to show how modularity is defined and used in some current modeling languages based on meta-meta-models. These languages are the MOF (Meta Object Facility) [MOF1997] submission which has been submitted to the OMG (Object Management Group) and CDIF [Ernst1997] (Case Data Interchange Format) as defined by the CDIF technical committee and standardized by the Electronic Industries Association. These two formalisms will be compared to a third one called sNets formalism [Bézivin1995] and based on semantic networks. We will explain in a first time why modeling needs modularity concepts. Then, we will describe how such concepts are defined and used in these formalisms. 1. Modularity needs in Modeling Modeling consists in representing increasingly complex information like data and processes descriptions. So, modularity is an essential concept in modeling. Without modularity, such set of information may be totally unusable. Then, meta-modeling is only a kind of modeling and modularity is needed in order to represents metamodels too. Modularity can be used for several purpose : • used to group elements (model elements, meta-model elements, as meta-meta-model elements) • may be used for classification (group modeling elements in different subject areas, etc...) • may allow the representation of the extension of such groups (ability to describe a group as an extension of an other group) • may allow nesting of such groups (in order to clarify organization) • may allow the representation of the dependencies between such groups (ability to describe the fact that elements defined in a group may rely on elements defined in an other group) 2. Modularity definition in various meta-meta-models A meta-model is used to describe models, so a meta-meta-model is used to describe meta-models. The concepts defined in a meta-model are depending on the concepts used in the model. In order to represent an object model, we must use a meta-model which defines concepts such as Class, Object, Inheritance, Method, etc... But if our aim is representing a petri model, we must use a meta-model which defines concepts such as places and transitions. Then, our aim here is representing meta-models, so we need concepts such as Concept also known as MetaEntity , and Relationship also known as Meta-Relationship. To simplify meta-model descriptions, other concepts may have been added in the meta-meta-model. These concepts are usually modularity and inheritance for concepts and relationships. Meta-meta-modeling is usually used to represent several meta-models. Then, modularity is an essential way to clearly identify each of these meta-models and to allow their extensions.In order to be used in meta-models, modularity concept needs to be defined in the meta-meta-model. 2.1. Modularity definition in the MOF submission The OMG is defining several different meta-models such as an Object Analysis and Design meta-model which is described in the Object Analysis and Design facility and a Workflow meta-model described in the Workflow management facility. So, the need for a common formalism in order to express these meta-models appears. The Meta Object facility has been created to define such a formalism. And the MOF submission has been submitted to the OMG organization to fulfill this request. So the modularity concept used in UML meta-model must be defined in the MOF submission. It must be said that the UML meta-model has been defined before the MOF. It has not been defined using the MOF semantics, but using the semantics it defines itself. So, a subset of UML semantics has been used as meta-meta-model for describing complete UML semantics. But this subset has not been clearly identified. And now, the MOF is supposed to be the UML semantics meta-model. This may explain why there is so many similarities between the MOF and UML (is that a good thing ? Since it makes sense to define a Class concept in the UML meta-model in order to define classes in models, does it makes sense to define a Class concept in a meta-meta-model ? ). Modularity in the MOF is obtained by the concept of name spaces (namespace) [ MOF, chap 3.7.2]. A namespace corresponds to a container for a set of modeling elements identified by their names. Moreover, one modeling element may be defined in one and only one namespace. This means that there is no general modularity mecanism which can be used to group unnamed elements. A namespace is an abstract concept. Indeed, regrouping modeling elements in MOF is done using the Package concept. But a class, an association and a data type are name spaces too. For example, the namespace of a MOF attribute is its class. Being given that a class, a package, an association, etc... , are namespaces, it's necessary to define constraints to specify which namespace can contain which kind of modeling elements. Such constraints are defined in the MOF using the OCL language [OCL1997]. Modularity in the MOF is represented by the Package concept [MOF1997, page 3-61] : "A Package is formed as composition of ModelElements. A package defines a modeling unit models are constructed and presented as packages. A model is a package. Packages are also used as organizational constructs in modeling nesting, importation and generalization are used to manage the complexity of models. Unlike a Classifier, a Package (an instance of Package Type, or the thing that instance represents) does not have instances." The term model used here must be seen as meta-model since it's a MOF definition and MOF models are metamodels (for example, UML meta-model is a MOF model). The last sentence means that a meta-model (which is a package) doesn't have intances. So, the relationship between a model and its meta-model isn't represented using the MOF meta-model. Package and Namespace definitions in the MOF are the following one [MOF1997, page 3-12] :